home *** CD-ROM | disk | FTP | other *** search
/ Internet Tools (InfoMagic) / Internet Tools.iso / dos_win / winsock / hacklist / 94-04.Z / 94-04 / 000001_rcq@mailserv-D.ftp.com_Thu Apr 3 04:47:47 1994.msg < prev    next >
Internet Message Format  |  1994-04-30  |  2KB
  1. Received: from ftp.com (wd40.ftp.com) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
  2.           id AA13125; Thu, 31 Mar 1994 09:48:35 -0500
  3. Received: from mailserv-D.ftp.com by ftp.com  ; Thu, 31 Mar 1994 09:48:34 -0500
  4. Received: from rcq.oysters.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4)
  5.     id AA11710; Thu, 31 Mar 94 09:47:47 EST
  6. Date: Thu, 31 Mar 94 09:47:47 EST
  7. Message-Id: <9403311447.AA11710@mailserv-D.ftp.com>
  8. To: paul@atlas.abccomp.oz.au
  9. Subject: Re: What does send() returning 0 mean ? revisited
  10. From: rcq@ftp.com  (Bob Quinn)
  11. Reply-To: rcq@ftp.com
  12. Cc: Multiple recipients of list <winsock-hackers@sunsite.unc.edu>
  13. Sender: rcq@mailserv-D.ftp.com
  14. Repository: mailserv-D.ftp.com, [message accepted at Thu Mar 31 09:47:34 1994]
  15. Originating-Client: oysters.ftp.com
  16. Content-Length: 1519
  17.  
  18. >   I'd like to conduct a straw-poll please, on the expected behaviour
  19. >   of calling send() with a zero length - this seems to be one
  20. >   case that different stacks handle quite differently, and there is currently
  21. >   no guidance in the specification.
  22. >   
  23. >           My thoughts are that this is a perfectly valid, though not
  24. >   particularly useful, thing to do, and that this is the only time it
  25. >   is valid for send() to return 0 - which indicates success, 'cause the
  26. >   number of bytes able to be written == number of bytes requested.
  27. >   Other stacks seem to call this an error, and Trumpet Winsock returns
  28. >   SOCKET_ERROR with error code WSAEINVAL (Invalid Argument) [ although the
  29. >   Error Codes section for send() indicates WSAEINVAL means "The socket
  30. >   has not been bound with bind()"]
  31. >   
  32. >           Comments from others, both stack developers and application
  33. >   developers, please ....
  34.  
  35. Since there is no obvious reason to reject a length of zero (it's
  36. not a useful request, but it's not a harmful one), we return 0.
  37. We did this partly because the spec is not clear on the issue,
  38. but also because we try to work on the philosophy that a function
  39. should not fail without good reason.  Since there are unforeseen
  40. conditions under which an application can sometimes mistakenly
  41. try to send 0 bytes, there's no reason for the DLL to punish
  42. them for it.
  43.  
  44. Regards,
  45. --
  46.  Bob Quinn                                             rcq@ftp.com
  47.  FTP Software, Inc.                                No. Andover, MA